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Abstract 


This specification defines the "Authentication-Info" and "Proxy- 
Authentication-Info" response header fields for use in Hypertext 
Transfer Protocol (HTTP) authentication schemes that need to return 
information once the client’s authentication credentials have been 


accepted. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7615. 
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Les 


Introduction 


This specification defines the "Authentication-Info" and "Proxy- 
Authentication-Info" response header fields for use in HTTP 
authentication schemes ([RFC7235]) that need to return information 
once the client’s authentication credentials have been accepted. 


Both were previously defined in Section 3 of [RFC2617], defining the 
HTTP "Digest" authentication scheme. This document generalizes the 
description for use not only in "Digest" ([RFC7616]), but also in 
other future schemes that might have the same requirements for 
carrying additional information during authentication. 


Notational Conventions 


This specification uses the Augmented Backus-Naur Form (ABNF) 
notation of [RFC5234] with a list extension, defined in Section 7 of 
[RFC7230], that allows for compact definition of comma-separated 
lists using a ’#’ operator (similar to how the ’*’ operator indicates 
repetition). The ABNF production for "“auth-param" is defined in 
Section 2.1 of [RFC7235]. 


The Authentication-Info Response Header Field 


HTTP authentication schemes can use the Authentication-Info response 
header field to communicate information after the client’s 
authentication credentials have been accepted. This information can 
include a finalization message from the server (e.g., it can contain 
the server authentication). 


The field value is a list of parameters (name/value pairs), using the 
"auth-param" syntax defined in Section 2.1 of [RFC7235]. This 
specification only describes the generic format; authentication 
schemes using Authentication-Info will define the individual 
parameters. The "Digest" Authentication Scheme, for instance, 
defines multiple parameters in Section 3.5 of [RFC7616]. 


Authentication-Info = #auth-param 


The Authentication-Info header field can be used in any HTTP 
response, independently of request method and status code. Its 
semantics are defined by the authentication scheme indicated by the 
Authorization header field ([RFC7235], Section 4.2) of the 
corresponding request. 


A proxy forwarding a response is not allowed to modify the field 
value in any way. 
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Authentication-Info can be used inside trailers ([RFC7230], 
Section 4.1.2) when the authentication scheme explicitly allows this. 


3.1. Parameter Value Format 


Parameter values can be expressed either as "token" or as "quoted- 
string" (Section 3.2.6 of [RFC7230]). 


Authentication scheme definitions need to allow both notations, both 
for senders and recipients. This allows recipients to use generic 
parsing components, independent of the authentication scheme in use. 


For backwards compatibility, authentication scheme definitions can 
restrict the format for senders to one of the two variants. This can 
be important when it is known that deployed implementations will fail 
when encountering one of the two formats. 


4. The Proxy-Authentication-Info Response Header Field 


The Proxy-Authentication-Info response header field is equivalent to 
Authentication-Info, except that it applies to proxy authentication 
((RFC7235], Section 2) and its semantics are defined by the 
authentication scheme indicated by the Proxy-Authorization header 
field ([RFC7235], Section 4.4) of the corresponding request: 


Proxy-Authentication-Info = #auth-param 


However, unlike Authentication-Info, the Proxy-Authentication-Info 
header field applies only to the next outbound client on the response 
chain. This is because only the client that chose a given proxy is 
likely to have the credentials necessary for authentication. 
However, when multiple proxies are used within the same 
administrative domain, such as office and regional caching proxies 
within a large corporate network, it is common for credentials to be 
generated by the user agent and passed through the hierarchy until 
consumed. Hence, in such a configuration, it will appear as if 
Proxy-Authentication-Info is being forwarded because each proxy will 
send the same field value. 


5. Security Considerations 


Adding information to HTTP responses that are sent over an 
unencrypted channel can affect security and privacy. The presence of 
the header fields alone indicates that HTTP authentication is in use. 
Additional information could be exposed by the contents of the 
authentication-scheme specific parameters; this will have to be 
considered in the definitions of these schemes. 
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6. IANA Considerations 


HTTP header fields are registered within the "Message Headers" 
registry located at <http://www.iana.org/assignments/ 
message-headers>, as defined by [BCP90]. 


This document updates the definitions of the "Authentication-Info" 
and "Proxy-Authentication-Info" header fields, so the "Permanent 
Message Header Field Names" registry has been updated accordingly: 


$--------------------------- + + + 
| Header Field Name | | | 
+--------------------------- +---------- +---------- +----------------- + 
| Authentication-Info | | | 


Section 3 of | 
this document | 


Proxy-Authentication-Info http standard Section 4 of 
this document 
4+--------------------------- 4+---------- +---------- 4+----------------- + 
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